Method and apparatus for providing service guide in a mobile broadcasting system

ABSTRACT

A method and apparatus for providing an SG in a mobile broadcasting system are provided. The apparatus and method include a terminal for receiving a first SG, for acquiring reception information about a second SG from the first SG, if a service fragment list extracted from the first SG includes information about at least one second SG different from the first SG, and for receiving the second SG based on the acquired reception information.

PRIORITY

This application claims the benefit under 35 U.S.C. §119(a) of a Koreanpatent application filed in the Korean Intellectual Property Office onOct. 5, 2007 and assigned Serial No. 2007-100604, the entire disclosureof which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a mobile broadcasting system supportinga Broadcast Service (BCAST). More particularly, the present inventionrelates to a method and apparatus for providing another Service Guide(SG) through a basic SG in a mobile broadcasting system.

2. Description of the Related Art

The mobile communication market faces ever-increasing demands for newservices through the recombination or convergence of existingtechnologies. The development of communications and broadcastingtechnologies has reached the point that a broadcasting service can beprovided through a portable terminal (hereinafter, a mobile terminal)such as a portable phone, a Personal Digital Assistant (PDA), etc. Withall of these potential and actual market demands, including the rapidlyincreasing user demands for multimedia service, the strategies ofservice providers that intend to provide new services including abroadcasting service beyond the conventional voice service, and theinterests of Internet Technology (IT) companies that reinforce mobilecommunication businesses by meeting customer demands, the convergencebetween mobile communications and Internet Protocol (IP) has been asignificant trend in the technological development of future-generationmobile communication systems. The resulting grand convergence, that is,the introduction of various wireless or broadcasting services to thewired communication market as well as the mobile communication markethas formed the same consumer environment for various servicesirrespective of wired or wireless broadcasting.

The Open Mobile Alliance (OMA) is an organization that works onstandardization of inter-operability between individual mobilesolutions. The OMA mainly serves to establish a variety of applicationstandards for mobile communication gaming, Internet service, etc. TheOMA BCAST working group is studying a technological standard forproviding a broadcasting service through a mobile terminal. That is, theOMA BCAST working group is underway to standardize techniques forproviding IP-based broadcasting services in a mobile terminalenvironment, including providing of a Service Guide (SG), download andstreaming transmission, service and content protection, servicesubscription roaming, etc.

Along with the market trend toward provisioning of integrated servicesbased on wired-wireless convergence, mobile broadcasting technologiesincluding OMA BCAST will also advance to provide services in awired-wireless integrated environment beyond the mobile environment.

FIG. 1 is a block diagram of a conventional structure for transmittingan SG to a mobile terminal in a mobile broadcasting system.

Referring to FIG. 1, interfaces between components (logical entities)illustrated in FIG. 1 will first be described in Table 1 and Table 2.

TABLE 1 Interface Description SG1 Server-to-server communications fordelivering content attributes such as description information, locationinformation, target terminal capabilities, target user profile, etc.either in the form of BCAST SG fragments or in a proprietary format. SG2Server-to-server communications for delivering BCAST service attributessuch as service/content description information, scheduling information,location information, target terminal capabilities, target user profile,etc. in the form of BCAST SG fragments. SG-B1 Server-to-servercommunications for either delivering Broadcast Distribution System (BDS)specific from BDS to BCAST SG Adaptation function, to assist SGadaptation to specific BDS, or to deliver BCAST SG attributes to BDS forBDS specific adaptation and distribution. SG4 Server-to-servercommunications for delivering provisioning information, purchaseinformation, subscription information, promotional information, etc., inthe form of BCAST SG fragments. SG5 Delivery of BCAST SG throughBroadcast Channel, over IP. SG6 Delivery of BCAST SG through InteractionChannel, interactive access to retrieve SG or additional informationrelated to SG, for example, by HTTP, SMS or MMS.

TABLE 2 Interface Description x-1 124 Reference Point between BDSService Distribution and BDS 122 x-2 125 Reference Point between BDSService Distribution and Interaction Network 123 x-3 126 Reference Pointbetween BDS 122 and Terminal 119 x-4 127 Reference Point between BDSService Distribution 121 and Terminal 119 over Broadcast Channel x-5 128Reference Point between BDS Service Distribution and Terminal overInteraction Channel (Air Interface 130) x-6 129 Reference Point betweenInteraction Network 123 and Terminal 119

Referring to FIG. 1, a content creator 101 creates a broadcast service(hereinafter, a BCAST service). The BCAST service can be a conventionalaudio/video broadcasting service or a conventional music/data filedownload service. In the content creator 101, an SG Content CreationSource (SGCCS) 102 transmits content description information, terminalcapabilities information, user profiles, and content timing informationrequired for configuring an SG for the BCAST service to an SGApplication Source (SGAS) 105 of a BCAST service application 104 via anSG1 interface 103 described in Table 1.

The BCAST service application 104 generates BCAST service data byreceiving data for the BCAST service from the content creator 101 andprocessing the data in a form suitable for a BCAST network. The BCASTservice application 104 also generates standardized meta data needed formobile broadcasting guidance. The SGAS 105 transmits informationreceived from the SGCCS 102 and sources required for configuring the SG,including service/content description information, schedulinginformation and location information, to an SG Generator (SG-G) 109 of aBCAST service distributor/adapter 108 via an SG2 interface 106 alsodescribed in Table 1.

The BCAST service distributor/adapter 108 establishes a bearer fordelivering the BCAST service data received from the BCAST serviceapplication 104, schedules transmission of the BCAST service, andgenerates mobile broadcasting guide information. The BCAST servicedistributor/adapter 108 is connected to a Broadcast Distribution System(BDS) 122, that transmits the BCAST service data, and to an interactionnetwork 123 that supports bi-directional communications.

The SG generated in the SG-G 109 is provided to a mobile terminal 119through an SG Distributor (SG-D) 110 and an SG-5 interface 117. If theSG needs to be provided through the BDS 122 or the interaction network123, or the SG needs to be adapted to suit a specific system or network,it is provided to the SG-D 110 after adaptation in an SG Adapter (SG-A)111, or to a later-described BDS service distributor 121 via an SG-B1interface 116.

A BCAST subscription manager 113 manages subscription informationrequired for BCAST service reception, service provision information, anddevice information about mobile terminals to receive the BCAST service.An SG Subscription Source (SGSS) 114 of the BCAST subscription manager113 transmits provisioning information, purchase information,subscription information, and promotional information in relation to SGgeneration to the SG-G 109 via an SG4 interface 112.

The BDS service distributor 121 distributes all received BCAST serviceson broadcast channels or on interaction channels. The BDS servicedistributor 121 is an optional entity that can be used or not dependingon the type of the BDS 122. The BDS 122 is a network over which theBCAST service is delivered. For example, the BDS 122 can be abroadcasting network such as Digital Video Broadcasting-Handheld(DVB-H), Multimedia Broadcast/Multicast Service (MBMS), or 3^(rd)Generation Partnership Project 2 (3GPP2) Broadcast Multicast Service(BCMCS). The interaction network 123 transmits the BCAST service in aone-to-one manner or exchanges control information and additionalinformation associated with BCAST service reception bi-directionally.For example, the interaction network 123 can be a legacy cellularnetwork.

In FIG. 1, the mobile terminal 119 is a BCAST reception-enabledterminal. Depending on its performance, the mobile terminal 119 can beconnected to a cellular network. The mobile terminal 119, which includesan SG Client (SG-C) 120, receives the SG via an SG5 interface 117 or anotification message via an SG6 interface 118 and appropriately operatesto receive the BCAST service.

Table 3, Table 4 and Table 5 summarize the functions of major components(logical entities) illustrated in FIG. 1, defined in the OMA BCASTstandards.

TABLE 3 Logical entity Description Content creator In the contentcreator, SGCCS may provide content attributes such 101 as contentdescription information, target terminal capabilities, target userprofile, content timing information, etc. and may send them over SG1 inthe form of standardized BCAST SG fragments or in a proprietary format.BCAST service In the BCAST service application, SGAS 105 providesapplication 104 service/content description information, schedulinginformation, location information, target terminal capabilities, targetuser profile, etc., and sends them over SG2 106 in the form ofstandardized BCAST SG fragments. BCAST In BCAST subscription manager,SGSS 114 provides provisioning subscription information, purchaseinformation, subscription information, manager 113 promotionalinformation, etc., and sends them over SG4 112 in the form of SGfragments.

TABLE 4 Logical entity Description SG-G 109 The SG-G in the network isresponsible for receiving SG fragments from various sources such asSGCCS 102, SGAS 105, SGSS 114 over SG-2 and SG-4 interfaces. SG-G 109assembles the fragments such as services and content access informationaccording to a standardized schema and generates SG which is sent toSG-D for transmission. Before transmission, it is optionally adapted inthe SG-A 111 to suit a specific BDS. SG-C 120 The SG-C in the terminal119 is responsible for receiving the SG information from the underlyingBDS and making the SG available to the mobile terminal. The SG-C obtainsspecific SG information. It may filter it to match the terminalspecified criteria (for example, location, user profile, terminalcapabilities), or it may simply obtain all available SG information.Commonly, the user may view the SG information in a menu, list ortabular format. SG-C may send a request to the network through SG-6 118to obtain specific SG information, or the entire SG.

TABLE 5 Logical entity Description SG-D 110 SG-D generates an IP flow totransmit SG over the SG5 interface 118 and the broadcast channel to theSG-C 120. Before transmission, the SG-G may send SG to SG-A 111 to adaptthe SG to suit specific BDS according to the BDS attributes sent by BDSservice distributor over SG-B1 116. The adaptation might result inmodification of SG. Note that, for adaptation purpose, the SG-A may alsosend the BCAST SG attributes or BCAST SG fragments over SG-B1 to BDSservice distributor for adaptation, this adaptation within BDS servicedistributor is out of the scope of BCAST, SG-D may also receive arequest for SG information, and send the requested SG information to theterminal directly through the interaction channel. SG-D also may filterSG information from SG-G 109 based on End Users pre-specified profile.SG-D may also send the SG to the BDS, which modifies the SG (e.g., byadding BSD specific information), and further distributes the SG to theSG-C in a BDS specific manner.

FIG. 2 illustrates a conventional OMA BCAST SG data model for generatingan SG. In FIG. 2, a solid line connecting fragments indicatescross-reference between the fragments.

Referring to FIG. 2, the SG data model includes an Administrative Group200 for providing upper configuration information about the entire SG, aProvisioning Group 210 for providing subscription information andpurchase information, a Core Group 220 for providing core informationabout the SG, such as services/contents and schedules, and an AccessGroup 230 for providing access information by which to access theservices/contents.

The Administrative Group 200 includes an SG Delivery Descriptor (SGDD)201 and the Provisioning Group 210 includes a Purchase Item 211, aPurchase Data 212, and a Purchase Channel 213.

The Core Group 220 includes a Service 221, a Schedule 222, and a Content223. The Access Group 230 is configured to include an Access 231 and aSession Description 232.

In addition to the four groups 200, 210, 220 and 230, the SG informationmay further include a Preview Data 241 and an Interactivity Data 251.The above-described components of the SG are called fragments, withminimum units constituting the SG.

As to the fragments, the SGDD fragment 201 provides information on adelivery session carrying an SG Delivery Unit (SGDU) with fragments,provides grouping information about the SGDU, and an entry point forreceiving a notification message.

The Service fragment 221 is an upper aggregate of content included in abroadcast service, as a core of the entire SG, and provides servicecontent, genres, service location information, etc.

The Schedule fragment 222 provides time information of the contentincluded in the service, such as streaming, downloading, etc.

The Content fragment 223 provides a description, a target user group, aservice area, and genres for the broadcast content.

The Access fragment 231 provides access information to allow the user toaccess the service, and also provides information about the deliveryscheme of an access session and session information about the accesssession.

The Session Description fragment 232 can be included in the Accessfragment 231. Alternatively, information about the location of theSession Description fragment 232 is given in the form of a UniformResource Identifier (URI), so that the terminal can detect the SessionDescription fragment 232. In addition, the Session Description fragment232 provides address information and codec information about multimediacontent included in a session.

The Purchase Item fragment 211 groups one or more multiple services orscheduled items together, so that the user can purchase a service or aservice bundle or subscribe to it.

The Purchase Data fragment 212 includes purchase and subscriptioninformation about services or service bundles, such as price informationand promotion information.

The Purchase Channel fragment 213 provides access information forsubscription to or purchase of a service or a service bundle.

The SGDD fragment 201 indicates an entry point for receiving the sericeguide and provides grouping information about an SGDU being a containerof fragments.

The Preview Data fragment 241 provides preview information aboutservices, schedules and contents, and the Interactivity Data fragment251 provides an interactive service during broadcasting according toservices, schedules, and contents. Detailed information on the SG can bedefined by various elements and attributes for providing contents andvalues based on the upper data model of FIG. 2.

For convenience, although the elements and attributes for each of thefragments of the SG are not included herein, the elements and attributesdo not limit the present invention, and the present invention isapplicable to all necessary elements and attributes defined to providean SG for a mobile broadcasting service.

In the course of generating a service guide in the SG-G 109 based on theSG data model and providing the fragments of the SG through the SG-D 110and the SG-C 120 being a user terminal, the more services and contentsthat service providers provide, the more information is transmitted. Theresulting exponential increase of the fragments of the SG in size andnumber may cause a significant increase in the overhead of receiving thefragments, in the time for assembling the SG and in the time andresources for displaying it in the terminal.

SUMMARY OF THE INVENTION

An aspect of the present invention is to address at least theabove-mentioned problems and/or disadvantages and to provide at leastthe advantages described below. Accordingly, an aspect of the presentinvention is to provide a method and apparatus for distributing a basicSG, first of all, to provide a service efficiently and enablingreception of complementary information about the basic SG or anotherstand-alone SG using the basic SG in a mobile broadcasting system.

In accordance with an aspect of the present invention, a method forreceiving an SG in a terminal in a mobile broadcasting system isprovided. The method includes receiving a first SG, if a servicefragment list extracted from the first SG includes information about atleast one second SG different from the first SG, reception informationabout the second SG is acquired from the first SG, and the second SG isreceived based on the acquired reception information.

In accordance with another aspect of the present invention, a method forproviding an SG in a mobile broadcasting system is provided. The methodincludes forming a first SG and at least one second SG, adding receptioninformation about the second SG to the first SG, transmitting the firstSG having the reception information about the second SG to a terminaland, when the terminal accesses the reception information about thesecond SG, the second SG is provided to the terminal.

In accordance with a further aspect of the present invention, anapparatus for receiving an SG in a terminal in a mobile broadcastingsystem is provided. The apparatus includes a broadcast data receiver forreceiving broadcasting data, an SG receiver for acquiring a first SG andat least one second SG from the broadcast data, an SG interpreter foracquiring reception information about the second SG by interpreting thefirst SG, and an SG display for displaying at least one of the acquiredfirst SG and the second SG.

In accordance with still another aspect of the present invention, anapparatus for providing an SG in a mobile broadcasting system isprovided. The apparatus includes an SG generator for forming a first SGand at least one second SG and for adding reception information aboutthe second SG to the first SG, and an SG transmitter for transmittingthe first SG having the reception information about the second SG to aterminal and for providing the second SG to the terminal, when theterminal accesses the reception information about the second SG.

Other aspects, advantages, and salient features of the invention willbecome apparent to those skilled in the art from the followingdescription, which, taken in conjunction with the annexed drawings,discloses exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features and advantages of certainexemplary embodiments of the present invention will be more apparentfrom the following description taken in conjunction with theaccompanying drawings, in which:

FIG. 1 is a diagram illustrating the logical structure of conventionalOMA BCAST SG functions;

FIG. 2 is a data model of a conventional OMA BCAST SG;

FIG. 3 illustrates a method for receiving an SG using a basic SGaccording to an exemplary embodiment of the present invention;

FIG. 4 is a flowchart illustrating an operation for receiving an SGusing a basic SG in a terminal according to an exemplary embodiment ofthe present invention;

FIG. 5 is an exemplary view of information in a Service fragment in anOMA BCAST SG data model;

FIG. 6 is an exemplary view of information in an Access fragment in anOMA BCAST SG data model; and

FIG. 7 is a block diagram of a system and a terminal according to anexemplary embodiment of the present invention.

Throughout the drawings, the same drawing reference numerals will beunderstood to refer to the same elements, features and structures.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The following description with reference to the accompanying drawings isprovided to assist in a comprehensive understanding of exemplaryembodiments of the invention as defined by the claims and theirequivalents. It includes various specific details to assist in thatunderstanding but these are to be regarded as merely exemplary.Accordingly, those of ordinary skill in the art will recognize thatvarious changes and modifications of the embodiments described hereincan be made without departing from the scope and spirit of theinvention. Also, descriptions of well-known functions and constructionsare omitted for clarity and conciseness.

While a description of exemplary embodiments of the present inventionwill be made herein using the names of the entities defined in the 3GPP,which is the asynchronous mobile communication standard, or defined inthe OMA BCAST, a standard group for the application of mobile terminals,the stated standards and entity names thereof are not intended to limitthe scope of the present invention, and the present invention can beapplied to any system having a similar technical background.

For a better understanding of exemplary embodiments of the presentinvention, a message scheme table used in the present invention will bedescribed with reference to Table 6.

TABLE 6 Name Type Category Cardinality Description Data Type

In Table 6, the term “Name” indicates the name of an entity being anelement or an attribute in a message. The term “Type” indicates whetherthe entity is an element or an attribute. If the entity is an element,it has a value of E1, E2, E3 or E4, wherein E1 indicates an upperelement in the entire message, E2 indicates a sub-element of E1, E3indicates a sub-element of E2, and E4 indicates a sub-element of E3. Ifthe entity is an attribute, its Type is A. For example, A under E1indicates an attribute of E1. The term “Category” indicates whether theelement or attribute is mandatory or optional. If the element orattribute is mandatory, Category is M and if it is optional, Category isO. The term “Cardinality” indicates the relationship between elements,and has a value of 0, 0 . . . 1, 1, 0 . . . n, or 1 . . . n. Herein, 0means an optional relationship, 1 means a mandatory relationship, and nmeans that a plurality of values can be used. For example, 0 . . . nmeans that the element may have no value, or n values. The term“Description” describes the element or attribute in plain text and theterm “Data Type” defines the data structure of the element or attribute.

FIG. 3 illustrates a method for receiving an SG and a method forproviding another SG using a basic SG according to an exemplaryembodiment of the present invention.

Referring to FIG. 3, the SG-C of a terminal (not shown) in a mobilebroadcasting system accesses an Announcement Session 301 and receives anSGDD 310 in the Announcement Session 301. As stated before, the SGDD 310includes an SGDU list and information about delivery sessions carryingSGDUs. In the exemplary implementation of FIG. 3, the SGDD 310 has anSGDU list containing fragments of a basic SG and information about adelivery session 302 (Delivery Session X) carrying intended SGDUs. Theterminal interprets the SGDD 310, accesses Delivery Session X, andreceives SGDUs 311 for the basic SG from Delivery Session X. Theterminal then extracts fragments for the basic SG from the SGDUs 311 anddisplays a final basic SG 320 to the user.

The basic SG 320 may include complementary information about a serviceor provide information about how to access an SG provided by anotherservice provider. In FIG. 3, the terminal can detect receptioninformation about a first SG 321 (SG 1) and a second SG 322 (SG 2) inthe basic SG 320. The reception information about SG1 includesinformation about a delivery session 303 (Delivery Session Y) carryingSGDUs 312 for SG 1 and the reception information about SG2 includesinformation about a delivery session 304 (Delivery Session Z) carryingSGDUs 313 for SG 2. The terminal accesses Delivery Session Y or DeliverySession Z, receives the SGDUs 312 for SG 1 or the SGDUs 313 for SG 2,and displays SG1 or SG2 to the user.

FIG. 4 is a flowchart illustrating an SG reception method in a terminalaccording to an exemplary embodiment of the present invention.

Referring to FIG. 4, the terminal accesses an Announcement Session andreceives an SGDD in the Announcement Session in step 401. In step 402,the terminal interprets the SGDD and detects information about adelivery session and SGDUs that carry fragments for an SG. The terminalreceives all of the SGDUs indicated by the SGDD from the deliverysession in step 403. The terminal extracts fragments from the SGDUs andconfigures an SG by interpreting the fragments in step 404 and checks alist of Service fragments in the SG in step 405. FIG. 5 is a diagramillustrating exemplary upper element values and attribute values of aService fragment.

In step 406, the terminal determines whether a ServiceType 501 (FIG. 5)set to Service Guide exists by interpreting the Service fragments of theService fragment list. In the absence of the ServiceType 501 set toService Guide, it can be considered that the SG contains onlyinformation that the terminal has received from a service provider,without information about provisioning of another SG. In this case, theterminal displays the SG to the user in step 407.

In the alternative, if the ServiceType 501 set to Service Guide doesexist, which implies the inclusion of information about reception of andaccess to another SG in the SG, the terminal detects all Accessfragments associated with the Service fragment with the ServiceType 501set to Service Guide in step 408. FIG. 6 is a diagram illustratingexemplary upper element values and attribute values of an Accessfragment.

In step 409, the terminal determines the value of a ServiceClass 601 ineach of the detected Access fragments. If the ServiceClass 601 is‘urn:oma:oma_bsc:sg:1.0’, this means that a delivery sessioncorresponding to access information included in the Access fragmentcarries a stand-alone SG. If the ServiceClass 601 is‘urn:oma:oma_bsc:csg:1.0’, this means that the delivery sessioncorresponding to the access information included in the Access fragmentcarries a complementary SG that provides complementary information aboutthe SG. Thus, the terminal acquires preliminary information about thestand-alone SG or the complementary SG by checking a sub-element of theServiceClass, ReferredSGInfo in step 410, which is given as follows.

TABLE 7 Data Name Type Category Cardinality Description Type Access E‘Access’ fragment Contains the following attributes: id versionvalidFrom validTo Contains the following elements: AccessTypeKeyManagementSystem EncryptionType ServiceReference ScheduleReferenceTerminalCapabilityRequirement BandwidthRequirement ServiceClassPreviewDataReference NotificationReception PrivateExt id A NM/ 1 ID ofthe ‘Access’ fragment. anyURI TM The value of this attribute SHALL beglobally unique. version A NM/ 1 Version of this fragment. TheunsignedInt TM newer version overrides the older one starting from thetime specified by the validFrom attribute, or as soon as it has beenreceived if no validFrom attribute is given. validFrom A NM/ 0 . . . 1The first moment when this unsignedInt TM fragment is valid. If notgiven, the validity is assumed to have started at some time in the past.This field contains the 32bits integer part of an NTP time stamp.validTo A NM/ 0 . . . 1 The last moment when this unsignedInt TMfragment is valid. If not given, the validity is assumed to end inundefined time in the future. This field contains the 32bits integerpart of an NTP time stamp. AccessType E1 NM/ 1 Defines the type ofaccess. TM Note: Either one of ‘BroadcastServiceDelivery’ or‘UnicastServiceDelivery’ but not both SHALL be instantiated.Implementation in XML Schema should use <choice>. Contains the followingelements: BroadcastServiceDelivery UnicastServiceDeliveryBroadcastServiceDelivery E2 NM/ 0 . . . 1 This element is used for theTM indication of IP transmission. Contains the following elements:BDSType SessionDescription FileDescription BDSType E3 NM/ 0 . . . 1Identifier of the type of TM underlying distribution system that this‘Access’ fragment relates to. Contains the following element: TypeVersion Type E4 NM/ 0 . . . 1 Type of underlying BDS, unsignedByte TMpossible values: 0. IPDC over DVB-H 1. 3GPP MBMS 2. 3GPP2 BCMCS 3-127.reserved for future use 128-255. reserved for proprietary use Version E4NM/ 0 . . . N Version of underlying BDS. string TM For instance,possible values are Rel-6 or Rel-7 for MBMS and 1x or HRPD or EnhancedHRPD for BCMCS. SessionDescription E3 NM/ 0 . . . 1 Reference to orinline copy of TM a Session Description information associated with this‘Access’ fragment that the media application in the terminal uses toaccess the service. Note: a referenced ‘SessionDescription’ fragment maybe delivered in two ways: via broadcast or via fetch over interactionchannel. In the case of fetch over interaction channel, the‘SessionDescription’ fragment can be acquired by accessing the URI(given as attribute of the different Session Description referenceelements). Contains the following elements: SDP SDPRef USBDRef ADPRefThe presence of elements ‘SDP’ and ‘SDPRef’ are mutually exclusive. If‘SessionDescription’ element is provided, and the ‘type’ attribute hasone of the values “4” or “5”, the terminal MAY use it instead offetching Session Description information via RTSP. SDP E4 NM/ 0 . . . 1An inlined Session Description string TM in SDP format [RFC 4566] thatSHALL either be embedded in a CDATA section or base64- encoded. Containsthe following attribute: encoding encoding A NM/TM 0 . . . 1 Thisattribute signals the way string the Session Description has beenembedded: It SHALL NOT be present when the Session Description isembedded into a CDATA section. It SHALL be present and set to “base64”in case the Session Description is base64- encoded. SDPRef E4 NM/TM 0 .. . 1 Reference to a Session Description in SDP format [RFC 4566]Contains the following attributes: uri idRef If both ‘uri’ and ‘idRef’are present, the referenced Session Description information SHALL beidentical. uri A NM/ 0 . . . 1 The URI referencing an anyURI TM externalresource containing SDP information. This URI is used for interactiveretrieval. idRef A NM/ 0 . . . 1 The id of the referenced anyURI TM‘SessionDescription’ fragment if the fragment is delivered over thebroadcast channel in SGDU, globally unique USBDRef E4 NM/TM 0 . . . 1Reference to an instance of MBMS User Service Bundle Description asspecified in [26.346] section 5.2.2, with the restrictions defined insection 5.1.2.5 of this spec. Contains the following attributes: uriidRef If both ‘uri’ and ‘idRef’ are present, the referenced SessionDescription information SHALL be identical. uri A NM/ 0 . . . 1 The URIreferencing an anyURI TM external resource containing MBMS-USBDinformation. This URI is used for interactive retrieval. idRef A NM/ 0 .. . 1 The id of the referenced anyURI TM ‘SessionDescription’ fragmentif the fragment is delivered over the broadcast channel in SGDU,globally unique ADPRef E4 NM/TM 0 . . . 1 Reference to anAssociatedDeliveryProcedure for File and Stream Distribution asspecified in [BCAST10-Distribution] section 5.3.4. Contains thefollowing attributes: uri idRef If both ‘uri’ and ‘idRef’ are present,the referenced Session Description information SHALL be identical. uri ANM/ 0 . . . 1 The URI referencing an anyURI TM external resourcecontaining AssociatedDeliveryProcedure for File and Stream Distribution.This URI is used for interactive retrieval. idRef A NM/ 0 . . . 1 The idof the anyURI TM referenced ‘SessionDescription’ fragment if thefragment is delivered over the broadcast channel in SGDU, globallyunique FileDescription E3 NO/ 0 . . . 1 File metadata for file deliveryTM sessions. This element SHALL be provided when ALC is used. Thiselement SHALL NOT be used in conjunction with FLUTE. The network SHALLsupport ‘FileDescription’ element and all its sub-elements andattributes if ALC is used for File Distribution function. Contains thefollowing attributes: Content-Type Content-EncodingFEC-OTI-FEC-Encoding-ID FEC-OTI-FEC-Instance-ID FEC-OTI-Maximum-Source-Block-Length FEC-OTI-Encoding-Symbol- Length FEC-OTI-Max-Number-of-Encoding-Symbols FEC-OTI-Scheme-Specific- Info Contains the followingelements: File Content- A NO/ 0 . . . 1 See RFC 3926, section 3.4.2string Type TM Content- A NO/ 0 . . . 1 See RFC 3926, section 3.4.2string Encoding TM FEC-OTI- A NO/TM 0 . . . 1 See RFC 3926, section3.4.2 unsignedByte FEC- Encoding- ID FEC-OTI- A NO/ 0 . . . 1 See RFC3926, section 3.4.2 unsignedLong FEC- TM Instance-ID FEC-OTI- A NO/ 0 .. . 1 See RFC 3926, section 3.4.2 unsignedLong Maximum- TM Source-Block- Length FEC-OTI- A NO/ 0 . . . 1 See RFC 3926, section 3.4.2unsignedLong Encoding- TM Symbol- Length FEC-OTI- A NO/ 0 . . . 1 SeeRFC 3926, section 3.4.2 unsignedLong Max- TM Number-of- Encoding-Symbols FEC-OTI- A NO/TM 0 . . . 1 This attribute MAY be used to base64Scheme- communicate FEC information Binary Specific- which is notadequately Info represented by the other attributes related to FEC. FileE4 NO/ 1 . . . N Parameters of a file. TM Contains the followingattributes: Content-Location TOI Content-Length Transfer-LengthContent-Type Content-Encoding Content-MD5 FEC-OTI-FEC-Encoding-IDFEC-OTI-FEC-Instance-ID FEC-OTI-Maximum-Source- Block-LengthFEC-OTI-Encoding-Symbol- Length FEC-OTI-Max-Number-of- Encoding-SymbolsFEC-OTI-Scheme-Specific- Info Content- A NO/ 1 See RFC 3926, section3.4.2 anyURI Location TM TOI A NO/ 1 See RFC 3926, section 3.4.2positiveInteger TM Content- A NO/ 0 . . . 1 See RFC 3926, section 3.4.2unsignedLong Length TM Transfer- A NO/ 0 . . . 1 See RFC 3926, section3.4.2 unsignedLong Length TM Content- A NO/ 0 . . . 1 See RFC 3926,section 3.4.2 string Type TM Content- A NO/ 0 . . . 1 See RFC 3926,section 3.4.2 string Encoding TM Content- A NO/ 0 . . . 1 See RFC 3926,section 3.4.2 base64 MD5 TM Binary FEC-OTI- A NO/TM 0 . . . 1 See RFC3926, section 3.4.2 unsignedByte FEC- Encoding- ID FEC-OTI- A NO/ 0 . .. 1 See RFC 3926, section 3.4.2 unsignedLong FEC- TM Instance-IDFEC-OTI- A NO/ 0 . . . 1 See RFC 3926, section 3.4.2 unsignedLongMaximum- TM Source- Block- Length FEC-OTI- A NO/ 0 . . . 1 See RFC 3926,section 3.4.2 unsignedLong Encoding- TM Symbol- Length FEC-OTI- A NO/ 0. . . 1 See RFC 3926, section 3.4.2 unsignedLong Max- TM Number-of-Encoding- Symbols FEC-OTI- A NO/TM 0 . . . 1 This attribute MAY be usedto base64 Scheme- communicate FEC information Binary Specific- which isnot adequately Info represented by the other attributes related to FEC.UnicastServiceDelivery E2 NM/ 0 . . . N This element indicates which TMserver and/or protocol is used for delivery of service over InteractionChannel. Contains the following attribute: type Contains the followingelements: AccessServerURL SessionDescriptionServiceAccessNotificationURL type A NM/ 1 Specifies transport mechanismunsignedByte TM that is used for this access. 0 - HTTP 1 - WAP 1.0 2 -WAP 2.x 3 - Generic RTSP to initialize RTP delivery 4 - RTSP toinitialize RTP delivery as per 3GPP-PSS (3GPP packet-switched streamingservice) 5 - RTSP to initialize RTP delivery as per 3GPP2-MSS (3GPP2multimedia streaming services) 6 - FLUTE over Unicast 7-127 Reserved forfuture use 128-255 Reserved for proprietary use Note: Specification ornegotiation of ports used for unicast service delivery is handled by theused unicast distribution mechanisms. For example, RTSP and PSS basedsystems (values 3 and 4) do port negotiation within the RTSP signallingexchange. AccessServerURL E3 NM/ 0 . . . N Server URL from which theanyURI TM terminal can receive the service via the Interaction Networkas specified in section 5.5 and 6.5 of [BCAST10- Distribution]. Forexample, AccessServerURL can be an HTTP URL pointing to downloadablecontent, or an RTSP URL pointing to a streaming server for starting astreaming session. If ‘type’ attribute has one of the values “3”, “4” or“5” either E3 element ‘SessionDescription’ or E3 element‘AccessServerURL’ or both SHALL be instantiated. SessionDescription E3NM/ 0 . . . 1 Reference to or inline copy of TM a Session Descriptioninformation associated with this ‘Access’ fragment that the mediaapplication in the terminal uses to access the service. Note: areferenced ‘SessionDescription’ fragment may be delivered in two ways:via broadcast or via fetch over interaction channel. In the case offetch over interaction channel, the ‘SessionDescription’ fragment can beacquired by accessing the URI (given as attribute of the differentSession Description reference elements). Contains the followingelements: SDP SDPRef USBDRef ADPRef The presence of elements ‘SDP’ and‘SDPRef’ are mutually exclusive. If ‘SessionDescription’ E3 element isinstantiated, and the ‘type’ attribute has one of the values “3”, “4” or“5”, the terminal MAY use it to acquire Session Description information(including RTSP URL) via broadcast channel or interaction channel using‘SDPRef’ or use inlined SDP (E4 element ‘SDP’), instead of fetchingSession Description information via RTSP. Further, in this case,‘AccessServerURL’ E3 element MAY NOT be present. If ‘type’ attribute hasone of the values “3”, “4” or “5” either E3 element ‘SessionDescription’or E3 element ‘AccessServerURL’ or both SHALL be instantiated. SDP E4NM/ 0 . . . 1 An inlined Session Description string TM in SDP format[RFC 4566] that SHALL either be embedded in a CDATA section or base64-encoded. Contains the following attribute: encoding encoding A NM/TM 0 .. . 1 This attribute signals the way string the Session Description hasbeen embedded: It SHALL NOT be present when the Session Description isembedded into a CDATA section. It SHALL be present and set to “base64”in case the Session Description is base64- encoded. SDPRef E4 NM/ 0 . .. 1 Reference to a Session TM Description in SDP format [RFC 4566]Contains the following attributes: uri idRef If both ‘uri’ and ‘idRef’are present, the referenced Session Description information SHALL beidentical. uri A NM/ 0 . . . 1 The URI referencing an anyURI TM externalresource containing SDP information. This URI is used for interactiveretrieval. The terminal SHALL support HTTP URI for this purpose. idRef ANM/ 0 . . . 1 The id of the referenced anyURI TM ‘SessionDescription’fragment if the fragment is delivered over the broadcast channel inSGDU, globally unique USBDRef E4 NM/TM 0 . . . 1 Reference to aninstance of MBMS User Service Bundle Description as specified in[26.346] section 5.2.2, with the restrictions defined in section 5.1.2.5of this spec. Contains the following attributes: uri idRef If both ‘uri’and ‘idRef’ are present, the referenced Session Description informationSHALL be identical. uri A NM/ 0 . . . 1 The URI referencing an anyURI TMexternal resource containing MBMS-USBD information. This URI is used forinteractive retrieval. idRef A NM/ 0 . . . 1 The id of the referencedanyURI TM ‘SessionDescription’ fragment if the fragment is deliveredover the broadcast channel in SGDU, globally unique ADPRef E4 NM/TM 0 .. . 1 Reference to an AssociatedDeliveryProcedure for File and StreamDistribution as specified in [BCAST10-Distribution] section 5.3.4.Contains the following attributes: uri idRef If both ‘uri’ and ‘idRef’are present, the referenced Session Description information SHALL beidentical. uri A NM/ 0 . . . 1 The URI referencing an anyURI TM externalresource containing AssociatedDeliveryProcedure for File and StreamDistribution. This URI is used for interactive retrieval. idRef A NM/ 0. . . 1 The id of the anyURI TM referenced ‘SessionDescription’ fragmentif the fragment is delivered over the broadcast channel in SGDU,globally unique ServiceAccessNotificationURL E3 NM/ 0 . . . N URL thatthe terminal anyURI TM SHOULD use to notify the BSD/A when it accesses(switches to) this service over this unicast access. The‘ServiceAccessNotificationURL’ MAY be used in conjunction with‘UnicastServiceDelivery’ types 3, 4, 5 or 6. If used, the device SHOULDNOT use RTSP TEARDOWN and RTSP SETUP to terminate an existing RTSPstream and set up a new one. The terminal SHALL NOT use this URL fornotification without user consent. Note: This URL can for example beused for initiating server-managed channel switching in unicasttransmission. KeyManagementSystem E1 NM/ 0 . . . N Information of Key TMManagement System(s)(KMS) that can be used to contact the BCASTPermissions Issuer and, in case of the SmartCard Profile whereby GBA isused for SMK derivation, whether GBA_U is mandatory or whether eitherGBA_ME or GBA_U can be used. Note that the BCAST Permissions Issuer cansupport more than one KMS. If KeyManagementSystem is not specified, itmeans no service or content protection is applied. Multiple occurrencesof ‘KeyManagementSystem’ elements are allowed within this fragment onlyif all of the ‘KeyManagementSystem’ elements have different ‘kmsType’attribute. Contains the following elements: ProtectionKeyIDPermissionsIssuerURI TerminalBindingKeyID Contains the followingattributes: kmsType protectionType kmsType A NM/ 1 Identifies the typeof Key unsignedByte TM Management System(s)(KMS). Possible values: 0.oma-bcast-drm-pki Indicates OMA BCAST DRM profile (Public KeyInfrastructure) 1. oma-bcast-gba_u-mbms Indicates BCAST Smartcardprofile using GBA_U (Symmetric Key Infrastructure) 2.oma-bcast-gba_me-mbms Indicates BCAST Smartcard profile using GBA_ME 3.oma-bcast-prov-bcmcs Indicates provisioned 3GPP2 BCMCS SKI 4-127Reserved for future use 128-255 Reserved for proprietary useprotectionType A NM/ 1 Specifies the protection type unsignedByte TMoffered by the KMS. Values: 0. Content protection only, as defined bythe LTKM (protection_after_reception in STKM = 0x00 or 0x01[BCAST10-ServContProt]) 1. Service protection only(protection_after_reception in STKM = 0x03 [BCAST10- ServContProt]) 2.Content protection as defined by LTKM, plus playback of protectedrecording permission (protection_after_reception in STKM = 0x02[BCAST10- ServContProt]) 3-127 Reserved for future use 128-255 Reservedfor proprietary use This attribute may also be used for presentationpurpose to users, to indicate whether the content item(s), associatedwith the referenced Schedule by this ‘Access’ fragment, is protected ornot. Permissions E2 NM/TM 1 The address of the BCAST anyURI IssuerURIPermissions Issuer to which requests for key material, tokens and/orconsumption rules should be sent by the BCAST Terminal. Contains thefollowing attribute: type type A NM/TM 1 The type of the booleanPermissionsIssuerURI, identified by the following values: false-DRMProfile true - Smartcard Profile Note: In the case of the DRM Profile,the PermissionsIssuerURI corresponds to the RightsIssuerURL as definedby [DRMDRM-v2.0]. In the case of the Smartcard Profile, thePermissionsIssuerURI corresponds to the network entity (i.e. the BSM) towhich all BCAST Service Provisioning messages are sent by the terminal.ProtectionKeyID E2 NO/ 0 . . . N Key identifier needed to access base64TO protected content. This Binary information allows the terminal todetermine whether or not it has the correct key material to accessservices within a PurchaseItem. In a scenario where this fragment isshared among multiple service providers, different key identifiers fromthe different service providers to access this specific protectedservice/content may be mixed in this element and the terminal SHOULD beable to sort out the key identifiers associated with the terminal'saffiliated service provider based on the Key Domain ID. How this is usedis out of scope and is left to implementation. The network and terminalSHALL support this element in case the Smartcard Profile is supported[BCAST10- ServContProt]. The protection key identifiers to access aspecific service or content item SHALL only be signalled in one of thefollowing fragment types: ‘Service’, ‘Content’, ‘PurchaseItem’ or‘Access’ fragments, but not mixed. Contains the following attribute:type type A NM/TM 1 Type of ProtectionKeyID: unsignedByte 0:ProtectionKeyID = Key Domain ID concatenated with SEK/PEK ID, where bothvalues are as used in the Smartcard Profile [BCAST10- ServContProt].1-127 Reserved for future use 128-255 Reserved for proprietary useTerminalBindingKeyID E2 NO/ 0 . . . 1 Number identifying the unsignedIntTO Terminal Binding Key ID (TBK ID) that is needed to access theservice. If the element is absent, no TerminalBindingKey is used. Boththe network and the terminal with the Smartcard Profile SHALL supportthis element. It is TM for terminals with the smartcard profile. Thiselement does not apply to the DRM profile. Contains the followingattribute: tbkPermissionsIssuerURI tbkPermissionsIssuerURI A NO/ 0 . . .1 Specifies the Permissions anyURI TM Issuer URI for theTerminalBindingKey if it is different from the ‘PermissionsIssuerURI’sub- element of the ‘KeyManagementSystem’ element. If the attribute isnot present the same ‘PermissionsIssuerURI’ indicated forKeyManagementSystem is used to acquire both SEK/ PEK andTerminalBindingKey. Encryption E1 NM/ 0 . . . N Specifies whichencryption unsignedByte Type TM methods the terminal is to be able tosupport in order to utilize this Access. Contains the same value astraffic_protection_protocol signalled in STKM. 0 - IPsec 1 - STRP 2 -ISMACryp 3 - DCF 4-255 - Reserved for future use. If this element is notpresent, this Access is not encrypted. ServiceReference E1 NM/ 0 . . . NReference to the ‘Service’ TM fragment(s) to which the ‘Access’ fragmentbelongs. Either one of ‘ServiceReference’ or ‘ScheduleReference’, orneither, but not both SHALL be instantiated. Each ‘Service’ fragmentSHALL be associated to at least one ‘Access’ fragment to enable theterminal to access the Service. A single ‘Access’ fragment MAY referenceto multiple ‘Service’ fragments. This is used when there are severalindependent descriptions of a single Service. idRef A NM/ 1Identification of the ‘Service’ anyURI TM fragment which this ‘Access’fragment is associated with. ScheduleReference E1 NM/ 0 . . . NReference to the ‘Schedule’ TM fragment(s) to which the ‘Access’fragment belongs. This provides a reference to a ‘Schedule’ fragment totemporarily override the default ‘Access’ fragment of the Serviceaddressed by the Schedule. Either one of ‘ServiceReference’ or‘ScheduleReference’, or neither, but not both SHALL be instantiated.Note: Implementation in XML Schema using <choice>. Contains thefollowing attribute: idRef Contains the following element:DistributionWindowID idRef A NM/ 1 Identification of the ‘Schedule’anyURI TM fragment which the ‘Access’ fragment relates to.DistributionWindowID E2 NO/ 0 . . . N Relation reference to theunsignedInt TM DistributionWindowID to which the ‘Access’ fragmentbelongs. The ‘DistributionWindowID’ element declared in this elementSHALL be the complete collection or a subset of the DistributionWindowids declared in the ‘Schedule’ fragment, to which ‘idRef’ referencebelongs. TerminalCapabilityRequirement E1 NO/ 0 . . . 1 Terminalcapabilities needed to TM consume the service or content. This elementprovides a hint to the terminal of what is needed to apply toconsumption method represented by this ‘Access’ fragment. It is out ofscope of this specification how the terminal applies this information.For video and audio, the media type and the related ‘type’ attribute inthe SDP (see section 5.1.2.5) signal the audio/video decoder. This way,these parameters complement the TerminalCapabilityRequirement.Additionally, the complexities of the audio/video streams are describedhere if they differ from the complexities which can be derived from themedia type attributes in the SDP (e.g. level). In this case, theparameters defined in the ‘Access’ fragment take priority. Contains thefollowing elements: Video Audio DownloadFile Video E2 NO/ 0 . . . 1Video codec capability related TM requirements Contains the followingelements: Complexity Complexity E3 NO/ 1 The complexity the video TMdecoder has to deal with. It is RECOMMENDED that this element isincluded if the complexity indicated by the MIME type parameters in theSDP differs from the actual complexity. Contains the following elements:Bitrate Resolution MinimumBufferSize Bitrate E4 NO/ 0 . . . 1 The totalbit-rate of the video TM stream. Contains the following attributes:average maximum average A NO/ 0 . . . 1 The average bit-rate in kbit/sunsignedShort TM maximum A NO/ 0 . . . 1 The maximum bit-rate in kbit/sunsignedShort TM Resolution E4 NO/ 0 . . . 1 The resolution of thevideo. TM Contains the following attributes: horizontal verticaltemporal horizontal A NO/ 1 The horizontal resolution of unsignedShortTM the video in pixels. vertical A NO/ 1 The vertical resolution of theunsignedShort TM video in pixels. temporal A NO/ 1 The maximum temporaldecimal TM resolution in frames per second. MinimumBufferSize E4 NO/ 0 .. . 1 The minimum decoder buffer unsignedInt TM size needed to processthe video content in kbytes. Audio E2 NO/ 0 . . . 1 The audio codeccapability. TM Contains the following element: Complexity Complexity E3NO/ 1 The complexity the audio TM decoder has to deal with. It isRECOMMENDED that this element is included if the complexity indicated bythe MIME type parameters in the SDP differs from the actual complexity.Contains the following elements: Bitrate MinimumBufferSize Bitrate E4NO/ 0 . . . 1 The total bit-rate of the audio TM stream. Contains thefollowing attributes: average maximum average A NO/ 0 . . . 1 Theaverage bit-rate in kbit/s unsignedShort TM maximum A NO/ 0 . . . 1 Themaximum bit-rate in kbit/s unsignedShort TM MinimumBufferSize E4 NO/ 0 .. . 1 The minimum decoder buffer unsignedInt TM size needed to processthe audio content in kbytes. DownloadFile E2 NO/ 0 . . . 1 The requiredcapability for the TM download files. Contains the following elements:MIMEType MIMEType E3 NO/ 1 . . . N Assuming a download service string TMconsists of a set of files with different MIME types which together makeup the service, the terminal must support all of these MIME types inorder to be able to present the service to the user. The format of thisstring SHALL follow the ‘Content-Type’ syntax defined in [RFC 2045].Additionally the ‘Content-Type’ MAY be augmented as defined in [RFC4281]. In the latter case the ‘Content- Type’ SHALL begin by“audio/3gpp”, “audio/3gpp2”, “video/3gpp”, “video/3gpp2” Contains thefollowing attribute: codec codec A NO/ 0 . . . 1 The codec parametersfor the string TM associated MIME Media type. If the file's MIME typedefinition specifies mandatory parameters, these MUST be included inthis string. Optional parameters containing information that can be usedto determine as to whether the terminal can make use of the file SHOULDbe included in the string. One example of the parameters defined foraudio/3GPP, audio/3GPP2, video/3GPP, video/3GPP2 is specified in[RFC4281]. BandwidthRequirement E1 NO/ 0 . . . 1 Specification of neededunsignedInt TM network bandwidth in kbit/s to the access channeldescribed in this fragment. A broadcast service can include multipleaccessible streams (same content) with different bandwidth, so that theterminal can make a choice depending on its current reception condition.ServiceClass E1 NM/ 1 The ServiceClass identifies the TM class ofservice. This identification is more detailed than the ‘ServiceType’element in the ‘Service’ fragment and allows the association ofservice/access combination to specific applications. Contains thefollowing attributes: urn Contains the following elements:ReferredSGInfo urn A NM/TM 1 Specifies the ServiceClass as stringdefined in OMNA registry (see Appendix E). The Terminal SHALL be able tointerpret the information. ReferredSG E2 NM/ 0 . . . 1 Specifies theadditional Info TM information for referred Service Guide. This elementSHALL be present only when ‘ServiceClass’ is“urn:oma:bcast:oma_bsc;csg:1.0” or “urn:oma:bcasst:oma_bsc:sg:1.0”.Contains the following elements: BSMSelector ServiceIDRefServiceGuideDeliveryUnit BSMSelector E3 NM/ 0 . . . N Specifies the BSMassociated TM with the referred Service Guide. Contains the followingattribute: idRef idRef A NM/TM 1 Reference to the identifier of anyURIthe BSMSelector declared within the ‘BSMList’ in theServiceGuideDeliverDescriptor which is used for receiving this fragment.SPName E4 NO/TM 0 . . . 1 Provides a user readable name string for theBSMSelector, possibly multiple language. Values should be the same asprovided in ServiceGuideDeliveryDescriptor referenced by idRef above.This element can be used to provide information to the user forselecting relevant referred Service Guide. ServiceIDRef E3 NM/TM 0 . . .1 The value of this field is the anyURI fragment ID of the ‘Service’fragment related to the referred Service Guide. ServiceGuideDeliveryUnitE3 NM/ 1 . . . N A group of fragments. TM Contains the followingattributes: transportObjectID, versionIDLength, contentLocation,validFrom, validTo Contains the following element: FragmenttransportObjectID A NM/ 0 . . . 1 The transport object ID of thepositiveInteger TM Service Guide Delivery Unit carrying the declaredfragments within this group. If ‘FileDescription’ is present in thisfragment, then the value of ‘transportObjectID’ SHALL match the value ofthe TOI paired in the FDT instance with the ‘Content-Location’ having asits value the value of the ‘contentLocation’ attribute below. If andonly if element E2 ‘Transport’ is instantiated, SHALL this attribute beinstantiated. versionIDLength A NO/ 0 . . . 1 Indicates the number ofleast unsignedLong TO significant bits representing the version ID inthe transportObjectID, when Split TOI is used. If this element isomitted, the terminal assumes Split-TOI is not used. contentLocation ANM/TM 1 This is the location of the anyURI Service Guide Delivery Unit.It corresponds to the ‘Content- Location’ attribute in the FDT. If andonly if element E2 ‘Transport’ is instantiated, SHALL this attribute beinstantiated. validFrom A NM/ 0 . . . 1 The first moment of time thisunsignedInt TM group of Service Guide fragments is valid. This fieldcontains the 32bits integer part of an NTP time stamp. Note: If thisattribute is not present, ‘validFrom’ attribute MUST be present in the‘Fragment’ sub-element. validTo A NM/ 0 . . . 1 The last moment of timethis unsignedInt TM group of Service Guide fragments is valid. Thisfield contains the 32bits integer part of an NTP time stamp. Note: Ifthis attribute is not present, ‘validTo’ attribute MUST be present inthe ‘Fragment’ sub-element. Fragment E4 NM/ 1 . . . N Declaration ofService Guide TM fragment. If the fragment is available over thebroadcast channel it MUST be present here. If the fragment is availableover the interaction channel it MAY be present here. Contains thefollowing attributes: transportID, id version validFrom validTofragmentEncoding fragmentType Contains the following element:GroupingCriteria transportID A NM/ 0 . . . 1 The identifier of theannounced unsignedInt TM Service Guide fragment to be used in theService Guide Delivery Unit header. Note: if the SG is delivered overthe broadcast channel only, this element MUST be present id A NM/ 1 Theidentifier of the announced anyURI TM Service Guide fragment. version ANM/ 1 The version of the announced unsignedInt TM Service Guidefragment. Note: The scope of the version is limited to the giventransport session. The value of version turn over from 2=− 1 to 0.validFrom A NM/ 0 . . . 1 The first moment when this unsignedInt TMfragment is valid. If not given, the validity is assumed to have startedat some time in the past. This field contains the 32bits integer part ofan NTP time stamp. Note: If this attribute is present and ‘validFrom’attribute of ‘ServiceGuideDeliveryUnit’ is also present, the value ofthis attribute overrides the value of ‘ServiceGuideDeliveryUnit’attribute ‘validFrom’. validTo A NM/ 0 . . . 1 The last moment when thisunsignedInt TM fragment is valid. If not given, the validity is assumedto end in undefined time in the future. This field contains the 32bitsinteger part of an NTP time stamp. Note: If this attribute is presentand ‘validTo’ attribute of ‘ServiceGuideDeliveryUnit’ is also present,the value of this attribute overrides the value of‘ServiceGuideDeliveryUnit’ attribute ‘validTo’. fragmentEncoding A NM/TM1 Signals the encoding of a unsignedByte Service Guide fragment, withthe following values: 0 - XML encoded OMA BCAST Service Guide fragment1 - SDP fragment 2 - MBMS User Service Description as specified in[26.346] (see 5.1.2.4, SessionDescriptionReference) 3 - XML encodedAssociated Delivery Procedure as specified in [BCAST10- Distribution]section 5.3.4. 4-127 - reserved for future BCAST extensions 128-255 -available for proprietary extensions fragmentType A NM/TM 0 . . . 1 Thisfield signals the type of an unsignedByte XML encoded BCAST ServiceGuide fragment, with the following values: 0 - unspecified 1 - ‘Service’Fragment 2 - ‘Content’ fragment 3 - ‘Schedule’ Fragment 4 - ‘Access’Fragment 5 - ‘PurchaseItem’ Fragment 6 - ‘PurchaseData’ Fragment 7 -‘PurchaseChannel’ Fragment 8 - ‘PreviewData’ Fragment 9 -‘InteractivityData’ Fragment 10-127 - reserved for BCAST extensions128-255 - available for proprietary extensions This attribute SHALL bepresent in case ‘fragmentEncoding’ = 0. Default: 0 PreviewDataReferenceE1 NM/ 0 . . . N Reference to the ‘PreviewData’ TM fragment whichspecifies the preview data (e.g. picture, video clip, or low-bit ratestream) associated with this access. It is possible that there are morethan one PreviewDataReference instances associated with the samefragment, in which case, the values of “usage” attributes of thesePreviewDataReference instances SHALL be different. Contains thefollowing attributes: idRef usage idRef A NM/ 1 Identification of theanyURI TM ‘PreviewData’ fragment which this fragment associated with.usage A NM/ 1 Specifies the usage of the unsignedByte TM associatedpreview data. Possible values: 0. unspecified 1. Service-by-ServiceSwitching 2. Service Guide Browsing 3. Service Preview 4. Barker 5.Alternative to blackout 6-127. reserved for future use 128-255. reservedfor proprietary use The explanation and limitation on the above previewdata usages is specified in section 5.7. Notification E1 NM/ 0 . . . 1Reception information for Reception TM service-specific NotificationMessages. In case of delivery over Broadcast channel,‘IPBroadcastDelivery’ specifies the address information for receivingNotification message. In case of delivery over Interaction channel,‘RequestURL’ specifies address information for subscribing notification,‘PollURL’ specifies address information for polling notification. Ifthis element is present, at least one of the elements“IPBroadcastDelivery”, “RequestURL”, or “PollURL” SHALL be present.Contains the following elements: IPBroadcastDelivery RequestURL PollURLIPBroadcast E2 NM/TM 0 . . . 1 Provides IP multicast address Deliveryand port number for reception of Notification Messages over thebroadcast channel. The ‘port’ is MANDATORY in both Network and Terminalbecause a designated UDP Port has to be used to deliver the NotificationMessage through an on-going session or the designated session while the‘address’ is OPTIONAL to be used for the delivery of NotificationMessages through the designated multicast or broadcast session. In casethe ‘address’ attribute is not provided the destination address providedby this access fragment SHALL be assumed. Contains the followingattributes: port address port A NM/ 1 Service-specific NotificationunsignedInt TM Message delivery UDP destination port number, deliveryover broadcast channel. address A NM/ 0 . . . 1 Service-specificNotification string TM Message delivery IP multicast address, deliveryover broadcast channel. RequestURL E2 NM/ 0 . . . 1 URL through whichthe anyURI TM terminal can subscribe to service-specific NotificationMessages. PollURL E2 NM/ 0 . . . 1 URL through which the anyURI TMterminal can poll service- specific Notification Messages. PrivateExt E1NO/ 0 . . . 1 An element serving as a TO container for proprietary orapplication-specific extensions. <proprietary E2 NO/TO 0 . . . NProprietary or application- elements> specific elements that are notdefined in this specification. These elements may further containsub-elements or attributes.

In step 411, the terminal receives the stand-alone SG or thecomplementary SG, forms the SG, and displays it to the user.

In relation to the present invention, ‘BSMSelector’, ‘ServiceIDRef’, and‘ServiceGuideDeliveryUnit’ are defined as sub-elements of ReferredSGInfoin Table 7. Other preliminary information about the stand-alone SG orthe complementary SG can be additionally provided by use of thesub-elements of ReferredSGInfo.

The uses of the sub-elements of ReferredSGInfo will be described below.

The sub-element BSMSelector specifies the service provider that providesthe stand-alone SG or the complementary SG. The service provider can beidentified by an IDentifier (ID) of a BSMSelector by idREF or anothername that the user can identify. In the former case, the terminal checksa BSMList defined in the SGDD used for receiving the basic SG, searchesfor BSMSelector information matching to the idRef in the BSMList, andacquires information such as a BSM code corresponding to the serviceprovider or a service provider name that the user can identify. Afterreceiving the stand-alone SG or the complementary SG, the terminal canclassify and manage the SG on a code or a service provider name basisusing the information. Or the basic SG may provide the information tothe user so that the user can selectively receive an SG. Thisinformation can be provided in the form of a user-identifiable namedirectly to the user by ‘SPName’ as well as in the form of an ID byidRef.

The sub-element ServiceIDRef indicates a service associated with thestand-alone SG or the complementary SG within the basic SG. ServiceIDRefincludes an ID identifying a Service fragment corresponding to theservice. Therefore, when ServiceIDRef includes an ID, the terminaldetects a Service fragment that matches the ID in the basic SG and isaware that the stand-alone SG or the complementary SG to be received isassociated with the detected Service fragment.

The sub-element ServiceGuideDeliveryUnit indicates SGDUs associated withthe stand-alone SG or the complementary SG in a delivery session thatthe Access fragment indicates. The service provider provides the basicSG and the stand-alone SG or the complementary SG in the same deliverysession by providing an SGDU list, so that SGs can be received,classified and managed according to the SGDU list.

FIG. 7 is a block diagram of a BCAST network system for providing aBCAST service and a BCAST terminal according to an exemplary embodimentof the present invention.

Referring to FIG. 7, a BCAST network system 710 can include the entitiesof the content creator 101, the BCAST service application 104, the BCASTservice distributor/adapter 108, and the BSCAST subscription manager 113illustrated in FIG. 1. In relation to an SG, the BCAST network system710 includes an SG source generator 711, an SG generator 712 and an SGtransmitter 713.

The SG source generator 711 can include the entities of the SGCCS 102,the SGAS 105, and the SGSS 114 illustrated in FIG. 1 and provides basicinformation about services and programs with which to generate an SG.

The SG generator 712 receives the SG generation information from the SGsource generator 711 and generates an SG using the SG generationinformation. The SG generator 712 may include the entities of the SG-G109 and the SG-A 111 illustrated in FIG. 1. The SG generator 712 alsogenerates SG fragments and defines cross-references between thefragments. Especially, the SG generator 712 defines cross-referencesbetween fragments for a basic SG, a stand-alone SG, and a complementarySG according to an exemplary embodiment of the present invention.

The SG transmitter 713 may include the entity of the SG-D 110. The SGtransmitter 713 is responsible for transmitting the SG generated fromthe SG generator 712. In particular, the SG transmitter 713 formsdelivery sessions to carry the basic SG and the stand-alone tocomplementary SG for the fragments generated by the SG generator 712 andtransmits the fragments in the delivery sessions in the exemplaryembodiment of the present invention.

A BDS 720 is a system that provides broadcast channels, including abroadcast transmission system 721 that can be DVB-H, 3GPP MBMS, 3GPP2BCMCS and the like.

A BCAST terminal 730 corresponds to the terminal 119 of FIG. 1. Inaccordance with an exemplary embodiment of the present invention, theBCAST terminal 730 receives, interprets and displays an SG. The BCASTterminal 730 may include a broadcast data receiver 731 for receivingbroadcast data, an SG receiver 732 for receiving an SG, an SGinterpreter 733 for interpreting the SG, and an SG display 734 fordisplaying the SG on a display 735.

The SG receiver 732, the SG interpreter 733, and the SG display 734perform the functions of the SG-C 120 illustrated in FIG. 1. Morespecifically, the SG receiver 732 receives the basic SG, the SGinterpreter 733 interprets fragments of the basic SG and the SG display734 displays the interpretation result on the display 735 for the userin the exemplary embodiment of the present invention. When the userselects an intended service, the BCAST terminal 730 acquires informationabout the selected service by checking an associated Access fragment inthe basic SG, receiving the Access fragment through the broadcast datareceiver 731 and the SG receiver 732, and interpreting it through the SGinterpreter 733. Then the BCAST terminal 730 displays the acquiredinformation on the display 735.

As is apparent from the above description, the present inventionprovides another SG through a basic SG. As a large SG can be distributedseparately as a basic SG and a complementary SG to the basic SG or astand-alone SG, SG transmission is more efficient. Earlier transmissionof the basic SG than others saves SG reception time and providesinformation to users more rapidly.

While the invention has been shown and described with reference tocertain exemplary embodiments thereof, it will be understood by thoseskilled in the art that various changes in form and details may be madetherein without departing from the spirit and scope of the presentinvention as defined by the appended claims and their equivalents.

1. A method for receiving a Service Guide (SG) in a terminal in a mobilebroadcasting system, the method comprising: receiving a first SG;acquiring, if a service fragment list extracted from the first SGincludes information about at least one second SG different from thefirst SG, reception information about the second SG from the first SG;and receiving the second SG based on the acquired reception information.2. The method of claim 1, wherein the receiving of the first SGcomprises: accessing an announcement session and receiving a ServiceGuide Delivery Descriptor (SGDD) in the announcement session; acquiringinformation about a delivery session carrying the first SG byinterpreting the SGDD; accessing the delivery session and receiving aService Guide Delivery Unit (SGDU) for the first SG in the deliverysession; extracting fragments of the first SG from the received SGDU;forming the first SG using the extracted fragments; and displaying thefirst SG.
 3. The method of claim 1, wherein the reception informationabout the second SG comprises information about a delivery sessioncarrying the second SG.
 4. The method of claim 3, wherein the receivingof the second SG comprises: accessing the delivery session carrying thesecond SG and receiving an SGDU for the second SG in the deliverysession; extracting fragments of the second SG from the SGDU for thesecond SG; forming the second SG using the extracted fragments; anddisplaying the second SG.
 5. The method of claim 4, wherein theacquiring of the reception information comprises: determining whetherthe extracted fragments of the first SG include a fragment with aservice type set to SG; checking information about the second SG in anaccess fragment associated with the fragment with a service type set toSG, in the presence of the fragment with a service type set to SG;forming the second SG based on the information; and displaying thesecond SG.
 6. The method of claim 5, wherein the information about thesecond SG comprises at least one of information about a service providerthat provides the second SG, the relationship between the second SG andthe first SG, and the relationship between the second SG and SGDUs forthe second SG.
 7. A method for providing a Service Guide (SG) in amobile broadcasting system, the method comprising: forming a first SGand at least one second SG; adding reception information about thesecond SG to the first SG; transmitting the first SG having thereception information about the second SG to a terminal; and providingthe second SG to the terminal, when the terminal accesses the receptioninformation about the second SG.
 8. The method of claim 7, wherein thetransmitting of the first SG comprises: providing a Service GuideDelivery Descriptor (SGDD) to the terminal, when the terminal accessesan announcement session; and providing a Service Guide Delivery Unit(SGDU) for the first SG to the terminal, when the terminal accesses adelivery session carrying the first SG by interpreting the SGDD.
 9. Themethod of claim 7, wherein the reception information about the second SGcomprises information about a delivery session carrying the second SG.10. The method of claim 9, wherein the reception information about thesecond SG further comprises at least one of information about a serviceprovider that provides the second SG, the relationship between thesecond SG and the first SG, and the relationship between the second SGand SGDUs for the second SG.
 11. An apparatus for receiving a ServiceGuide (SG) in a terminal in a mobile broadcasting system, the apparatuscomprising: a broadcast data receiver for receiving broadcasting data;an SG receiver for acquiring a first SG and at least one second SG fromthe broadcast data; an SG interpreter for acquiring receptioninformation about the second SG by interpreting the first SG; and an SGdisplay for displaying at least one of the acquired first SG and thesecond SG.
 12. The apparatus of claim 11, wherein the SG receiverreceives a Service Guide Delivery Descriptor (SGDD) in an announcementsession, when the terminal accesses the announcement session, and the SGinterpreter acquires information about a delivery session carrying thefirst SG by interpreting the SGDD.
 13. The apparatus of claim 12,wherein the SG receiver accesses the delivery session carrying the firstSG and receives a Service Guide Delivery Unit (SGDU) for the first SG inthe delivery session, and the SG interpreter extracts fragments of thefirst SG from the received SGDU.
 14. The apparatus of claim 11, whereinthe reception information about the second SG comprises informationabout a delivery session carrying the second SG.
 15. The apparatus ofclaim 14, wherein the SG receiver accesses the delivery session carryingthe second SG and receives an SGDU for the second SG in the deliverysession and the SG interpreter extracts fragments of the second SG fromthe SGDU for the second SG.
 16. The apparatus of claim 15, wherein theSG interpreter determines whether the extracted fragments of the firstSG include a fragment with a service type set to SG, checks informationabout the second SG in an access fragment associated with the fragmentwith a service type set to SG, in the presence of the fragment with aservice type set to SG, and forms the second SG based on theinformation.
 17. The apparatus of claim 16, wherein the informationabout the second SG comprises at least one of information about aservice provider that provides the second SG, the relationship betweenthe second SG and the first SG, and the relationship between the secondSG and SGDUs for the second SG.
 18. An apparatus for providing a ServiceGuide (SG) in a mobile broadcasting system, the apparatus comprising: anSG generator for forming a first SG and at least one second SG and foradding reception information about the second SG to the first SG; and anSG transmitter for transmitting the first SG having the receptioninformation about the second SG to a terminal, and for providing thesecond SG to the terminal, when the terminal accesses the receptioninformation about the second SG.
 19. The apparatus of claim 18, whereinthe SG transmitter provides a Service Guide Delivery Descriptor (SGDD)to the terminal, when the terminal accesses an announcement session, andprovides a Service Guide Delivery Unit (SGDU) for the first SG to theterminal, when the terminal accesses a delivery session carrying thefirst SG by interpreting the SGDD.
 20. The apparatus of claim 19,wherein the reception information about the second SG comprisesinformation about a delivery session carrying the second SG.
 21. Theapparatus of claim 20, wherein the reception information about thesecond SG further comprises at least one of information about a serviceprovider that provides the second SG, the relationship between thesecond SG and the first SG, and the relationship between the second SGand SGDUs for the second SG.